home *** CD-ROM | disk | FTP | other *** search
- Path: Norway.EU.net!usenet
- From: patrick.hanevold@login.eunet.no (Patrick Hanevold)
- Newsgroups: comp.sys.amiga.programmer
- Subject: Re: Is a real good mpeg player possible on the amiga ?
- Date: 4 Feb 1996 17:36:04 GMT
- Organization: EUnet Norway
- Message-ID: <1242.6607T896T551@login.eunet.no>
- References: <4e2gqu$5ca@caers3.unicaen.fr> <4e2o57$5a2@serpens.rhein.de><574.6598T297T795@login.eunet.no>
- <4e7n75$krh@serpens.rhein.de><386.6603T1404T1784@login.eunet.no> <PETERM.96Feb1112250@tui.maths.irl.cri.nz>
- NNTP-Posting-Host: pc3.asker-pm2-1.eunet.no
- X-Newsreader: THOR 2.22 (Amiga;TCP/IP)
-
-
- >>Yes. They happen to be coded very slow. Just like MP.
- >>Maby some asm would help a little?
-
- >I tried compiling the Unix mpeg_play v1.2 first with optimised SAS/C,
- >then later with optimised GNU C, with appropriate changes for CGraphX
- >(no c2p). In both cases the result ran about twice as slow as mp103.
- >Rewriting the critical parts in asm would probably achieve about the
- >same speed as mp103. To get significantly more speed, we need a
- >faster algorithm (if one exists), I think.
-
- >I haven't followed all the details, but I can see that mpeg_play
- >calculates YUV for each frame in one buffer, then converts it to RGB
- >in another buffer, then finally renders it to the display device (in
- >my case with cybergraphics.library WritePixelArray()). It is
- >conceivable that combining these operations could save a lot of memory
- >reads/writes. Unfortunately I can't see how to do it because the YUV
- >and RGB frames are calculated in non-sequential order and saved in
- >buffers until they are needed.
-
- The sources I've seen, well.. they are slow coded, and compared to MP, the
- speed was about the same, a little slower.
-
- <sb>Patrick Hanevold - Virtual Reality developer
- <sb>patrick.hanevold@login.eunet.no
- <sb>Amiga and official Be developer
-
-